Method and Apparatus for Tunneling Information in RFID Communications

ABSTRACT

A method and apparatus involve a radio frequency identification tag that receives a wireless signal containing a message type conforming to an extension of a standard communication protocol and having an extended services segment, the tag then transmitting the extended services segment through an extended services interface. According to a different aspect, a method and apparatus involve a radio frequency identification tag that stores data which includes respective information regarding each of multiple extended services, and that responds to receipt of a wireless signal which is an extension to a standard protocol by transmitting a further wireless signal which is an extension to the protocol and contains at least part of the data. According to yet another aspect, a method and apparatus involve a radio frequency identification tag that responds to receipt of one wireless signal by transmitting a further wireless signal containing information regarding multiple sensors.

This application claims the priority under 35 U.S.C. §119 of provisionalapplication No. 61/182,444 filed May 29, 2009, the entire disclosure ofwhich is hereby incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates in general to radio frequency identification(RFID) systems and, more particularly, to techniques that enhance thefunctionality of RFID tags, including enhancement of sensorfunctionality in tags.

BACKGROUND

Radio frequency identification (RFID) systems are used for a variety ofdifferent applications. As one example, RFID systems are commonly usedto track and monitor shipping containers or other mobile assets. RFIDtags are attached to the shipping containers or other assets, andexchange wireless communications with other system components, includingstationary interrogators and/or readers.

Over time, RFID tags are being provided with a progressively increasingdegree of extended functionality, above and beyond that needed for basicRFID operation. These optional extended functions are sometimes referredto as “extended services”. As one aspect of this, extended services maybe implemented by adding supplemental hardware and/or softwarecomponents to a tag. For example, a tag may include one or more sensors,along with a software module that handles the sensors. As anotherexample, a tag may include a global positioning system (GPS) receiver,along with a software module that processes data from the GPS receiver.As yet another example, a tag may include a software module thatprovides enhanced security for wireless communications, by encryptingand decrypting information being sent and received by the tag.

Many RFID tags and interrogators are currently being manufactured tocommunicate according to a protocol that is an international standardcommonly known as ISO 18000-7. Although this protocol has been generallyadequate for its intended purposes, it has not been entirelysatisfactory in all respects. As one example, this protocol does notallow an interrogator to efficiently obtain from a given tag anidentification of all the extended services that are implemented on thetag.

A further consideration is that there are industry-standard protocolsthat can be used to interact with a single sensor. One example is ISO21451.7, which is based on another industry-standard protocol commonlyknow as IEEE 1451.7. Although the ISO 21451.7 protocol has beengenerally adequate for its intended purposes, it has not been entirelysatisfactory in all respects. As one aspect of this, there is currentlyno convenient way to use this protocol in conjunction with the ISO18000-7 protocol, so that an interrogator can directly and efficientlycommunicate with a sensor that is provided in a tag. As another aspect,the ISO 21451.7 protocol is specifically designed for interaction withonly a single sensor. Thus, in addition to the fact that there iscurrently no way to use the ISO 21451.7 protocol in conjunction with theISO 18000-7 protocol, where a tag has multiple sensors it would benecessary for the tag to be simultaneously running several separate,identical instantiations of a single-sensor software module for ISO21451.7 (one module for each sensor). This would obviously be verycumbersome and inefficient.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of aspects of the present invention will berealized from the detailed description that follows, taken inconjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of an apparatus that is a radio frequencyidentification (RFID) system, that includes an interrogator and a tag,and that embodies aspects of the present invention.

FIG. 2 is a diagrammatic view showing the format of a universal datablock (UDB) that is used for transfers of certain types of data.

FIG. 3 is a diagrammatic view showing some data that is stored in amemory of the system of FIG. 1.

FIG. 4 is a diagrammatic view of a digital word contained in wirelesssignals transmitted from the interrogator to the tag of FIG. 1.

FIG. 5 is a diagrammatic view of a digital word contained in wirelesssignals transmitted from the tag to the interrogator of FIG. 1.

FIG. 6 is a diagrammatic view of one example of a command that canappear in the digital word of FIG. 4.

FIG. 7 is a diagrammatic view of one example of a response that is areply to the command of FIG. 6, and that can appear in the digital wordof FIG. 5.

FIG. 8 is a diagrammatic view of another example of a command that canappear in the digital word of FIG. 4.

FIG. 9 is a diagrammatic view of another example of a response that is areply to the command of FIG. 8, and that can appear in the digital wordof FIG. 5.

FIG. 10 is a diagrammatic view of one example of UDB data that canappear in the response of FIG. 9.

FIG. 11 is a diagrammatic view of another example of UDB data that canappear in the response of FIG. 9.

FIG. 12 is a diagrammatic view of yet another example of UDB data thatcan appear in the response of FIG. 9.

FIG. 13 is a diagrammatic view of an example of a payload that containsa command, and that could appear in the command of FIG. 6.

FIG. 14 is a diagrammatic view of an example of a payload that containsa reply to the command of FIG. 13, and that could appear in the responseof FIG. 7.

FIG. 15 is a diagrammatic view of another example of a payload thatcontains a command, and that could appear in the command of FIG. 6.

FIG. 16 is a diagrammatic view of an example of a payload that containsa reply to the command of FIG. 15, and that could appear in the responseof FIG. 7.

FIG. 17 is a diagrammatic view of yet another example of a payload thatcontains a command, and that could appear in the command of FIG. 6.

FIG. 18 is a diagrammatic view of an example of a payload that containsa reply to the command of FIG. 17, and that could appear in the responseof FIG. 7.

FIG. 19 is a diagrammatic view of an example of a payload that containsan alternative reply to any of the commands of FIG. 13, 15 or 17, andthat could appear in the response of FIG. 7.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an apparatus that is a radio frequencyidentification (RFID) system 10, and that embodies aspects of thepresent invention. The system 10 includes an RFID tag 11, aninterrogator 12, and a control system 13. The interrogator 12 is adevice that is also sometimes referred to as a reader. The system 10actually includes many tags of the type shown at 11, and severalinterrogators of the type shown at 12. However, for simplicity andclarity in the discussion that follows, only one tag 11 and oneinterrogator 12 are shown and described. In the disclosed embodiment,the interrogator 12 is stationary, and the tag 11 can move relative toit. For example, the tag 11 may be mounted on a not-illustrated shippingcontainer, on a vehicle (such as a truck or forklift), on an item thatis being transported (such as a box containing a television set), or onsome other type of mobile asset. Although the interrogator 12 in thedisclosed embodiment is stationary, it would alternatively be possiblefor the interrogator to be mobile. And if the interrogator 12 is mobile,then it would alternatively be possible for the tag 11 to be stationary.

With reference to the interrogator 12, FIG. 1 does not show all of thecircuitry present within the interrogator, but instead shows onlyselected portions of the circuitry that are relevant to an understandingof aspects of the present invention. The interrogator 12 includes amicrocontroller 21. Persons skilled in the art are familiar with thefact that a microcontroller is an integrated circuit containing amicroprocessor, a read-only memory (ROM), and a random access memory(RAM). The ROM stores a computer program that is executed by themicroprocessor, along with static data used by the microprocessor. TheRAM stores dynamic data that is changed by the microprocessor duringsystem operation. The interrogator 12 includes a network interface 22that is coupled to the microcontroller 21, and that is also coupledthrough a network 23 to the control system 13. In FIG. 1, the network 23is a type of network commonly referred to in the art as an Ethernetnetwork. However, the network 23 could alternatively be any othersuitable type of network or communications system.

The interrogator 12 also includes an ultra high frequency (UHF)transceiver 26, and an antenna 27 through which the transceiver can sendand receive wireless signals 28. The wireless signals 28 containinformation that is explained in more detail later. In the embodiment ofFIG. 1, the wireless signals 28 are generated by frequency shift keying(FSK) to modulate information onto a radio frequency (RF) carriersignal. However, it would alternatively be possible to use some othertype of modulation. In the disclosed embodiment, the carrier signal hasa frequency of 433.92 MHz, but it could alternatively have any othersuitable frequency. One possible alternative frequency is 915 MHz.However, the disclosed embodiment uses 433.92 MHz because it isavailable for use in a larger number of countries under prevailinggovernmental regulations regarding the transmission of electromagneticsignals. In the disclosed embodiment, the wireless signals 28 have atransmission range of about 300 feet, but the transmission range couldalternatively be larger or smaller.

As to the wireless signals 28 transmitted between the interrogator 12and tag 11, the interrogator and tag in the disclosed embodiment cancommunicate using an existing international industry standard known asISO 18000-7. This international standard was promulgated by theInternational Organization for Standardization (ISO), which isheadquartered in Geneva, Switzerland. Persons skilled in the art arefamiliar with the ISO 18000-7 standard. As used herein, the term ISO18000-7 refers to a specific version of the standard, which is ISO/IECFDIS 18000-7:2009(E). Although the interrogator 12 and tag 11 cancommunicate in conformity with the ISO 18000-7 standard, they can alsocommunicate in new and unique ways that are not currently part of the18000-7 standard, but are potential enhancements or extensions thatcould be added to the 18000-7 standard. These enhancements or extensionsare discussed later.

Turning to the tag 11, FIG. 1 does not show everything that is presentin the tag 11, but instead shows only selected portions that arerelevant to an understanding of aspects of the present invention. Thetag 11 includes a UHF transceiver 41, and an antenna 42 through whichthe transceiver 41 can send and receive wireless signals, including thewireless signals 28. The tag 11 also includes a microcontroller 46having a processor 47 and a memory 48. In FIG. 1, the memory 48 is adiagrammatic representation of all types of memory that happen to bepresent within the microcontroller 46, including ROM, RAM, flash memory,and/or any other type of storage. Some of the information stored in thememory 48 is discussed later.

The tag 11 includes a temperature sensor 51 and a shock sensor 52, whichare located within a housing of the tag 11. The temperature sensor 51monitors the ambient temperature within the tag, which corresponds tothe ambient external temperature near the tag. The shock sensor 52 candetect the magnitude of a physical shock experienced by the tag or by anasset to which the tag is attached, for example where the tag or assetis struck with force by some other object. A humidity sensor 53 isprovided externally of the tag 11. The humidity sensor 53 may be mountedon the exterior of the housing of the tag, or may be mounted on someother structure that is spaced some distance from the tag. The sensors51-53 are each operatively coupled to the microcontroller 46, either bywires, or by some form of wireless link, such as an infrared (IR) or anRF link. For example, wires 54 couple the humidity sensor 53 to themicrocontroller 46 within the tag 11. The temperature sensor 51, shocksensor 52 and humidity sensor 53 shown in FIG. 1 are merely exemplary.The system 10 could have various other types of sensors, and could havea larger or smaller number of sensors. Moreover, any given sensor couldbe located either inside or outside of the tag 11.

The tag 11 includes a global positioning system (GPS) receiver 57, andan associated antenna 58. Through the antenna 58, the GPS receiver 57can receive standard wireless GPS signals 59 transmitted by severalconventional GPS satellites that orbit the earth, and that arerepresented diagrammatically at 61 in FIG. 1. The GPS signals fromsatellites 61 include standard GPS positioning information that can beused in a known manner to calculate the location of the tag 11 on thesurface of the earth.

The tag 11 includes a battery 63 that powers all of the circuitry withinthe tag, as well as the external humidity sensor 53. Alternatively, thehumidity sensor 53 could have a separate battery. In the disclosedembodiment, the battery 63 is a long-lasting lithium battery of a knowntype, but could alternatively be some other type of battery.

Referring again to the microcontroller 46, the memory 48 stores severalcomputer programs that are executed by the processor 47, including amain program 71, a sensor application 72, a security application 73, areal time locating system (RTLS) application 74, and a GPS application75. The main program 71 provides the basic functionality of the tag,including RFID functionality. The sensor application 72 manages all ofthe sensors 51-53 that are associated with the tag 11, and maintainssome data 77 regarding the sensors. The data 77 is discussed later. Thesecurity application 73 provides enhanced security, for example byencrypting and decrypting information being sent and received via thewireless signals 28, and by verifying for the tag 11 the authenticity ofthe remote interrogator 12 as a device that is authorized to communicatewith the tag. The RTLS application 74 supplements the RFID functionalityof the tag 11 by providing RTLS capability of a type that is known inthe art, and that is therefore not described here in detail. The GPSreceiver 57 provides the GPS application 75 with position informationextracted from the GPS signals 59, and the GPS application 57 uses thisposition information to calculate the current location of the tag 11 onthe surface of the earth.

The application programs 72-75 each provide a service that supplementsor extends the capabilities of the main program 71 of the tag. Theapplication programs 72-75 are therefore collectively referred to hereinas extended services 81. The communication between the main program 71and each of the application programs 72-75 is referred to as an extendedservices interface 82. The application programs 72-75 shown in FIG. 1are merely exemplary. The tag 11 could have other types of extendedservices that are not illustrated and described here. Although FIG. 1happens to show four types of extended services at 72-75, the tag 11could have a larger or smaller number of extended services, or couldhave no extended services at all. In the disclosed embodiment, the tag11 is configured to handle a maximum of 16 extended services 81.Alternatively, however, the maximum number of extended services could behigher or lower.

The memory 48 of the microcontroller 46 has a portion set aside to storeuniversal data block (UDB) data 86. A UDB is an industry-standard formatfor transmitting data. FIG. 2 is a diagrammatic view showing thestandard format of a UDB 88. The UDB 88 has N similar data slots, whereN is an integer. Each of the N data slots has the same format, includingthe same three fields. These three fields are a type field, a lengthfield and a data field. The data field contains the actual data, and hasa length that corresponds to the amount of data. The type fieldidentifies the type of data in the data field, and the length fieldidentifies the actual length of the data field in bytes. The number N ofdata slots in the UDB 88 is not fixed, but can be varied in order toaccommodate the number of data items that need to be transferred in agiven situation. The data in the data field can optionally includemultiple elements that each have the three-field type-length-data (TLD)format. In other words, a TLD block or data slot can be nested withinthe data field of another TLD block or data slot. A detailed explanationof UDBs is provided in U.S. Pat. No. 7,434,731, the entire disclosure ofwhich is hereby incorporated herein by reference.

FIG. 3 is a diagrammatic view showing some of the UDB data stored at 86in the memory 48 (FIG. 1). FIG. 3 does not show all of the data storedin the UDB data 86, but only selected items that are relevant to anunderstanding of aspects of the present disclosure. In this disclosure,when “0x” precedes a group of characters, it is an indication that thecharacters are in hexadecimal format. The UDB data 86 includes a groupof data elements that are collectively referred to as UDB type 0x00. Twoof the elements in this UDB type are an extended services list 91 and analarm summary list 93. The extended services list 91 is a list of allthe extended services 81 (FIG. 1) that are currently installed on thetag 11. The alarm summary list 93 is a list of all currently-activealarms that are associated with the extended services applications 81.For example, if the temperature detected by the temperature sensor 51 iscurrently in excess of a specified upper limit, then that constitutes analarm condition that would be reflected in the alarm summary list 93.The extended services list 91 and the alarm summary list 93 are not partof the ISO 18000-7 standard, but instead are potential enhancements orextensions that could be added to the 18000-7 standard.

The UDB data 86 also includes sixteen UDB types 0x80 through 0x8F thatare respective memory blocks or storage sections 101-116. The storagesections 101-116 are sometimes referred to herein as mailboxes. Each ofthe extended services 81 actually present on the tag 11 is assigned arespective one of the storage sections 101-116. In this regard, each ofthe extended services 81 on the tag is assigned a unique extendedservices identifier (ESID), which is a value from 0x80 to 0x8F. TheseESIDs are uniquely defined for each tag, based on the set of extendedservices actually installed on that particular tag. Thus, for example,the GPS application 75 may have an ESID of 0x80 on one tag, an ESID of0x83 on another tag, and an ESID of 0x8F on yet another tag. Althougheach of the extended services 81 is assigned only one mailbox in thedisclosed embodiment, it would alternatively be possible for an extendedservice to be assigned two or more of the mailboxes.

The storage sections 101-116 are each used for transmission ofinformation between a respective one of the extended servicesapplications 81 and other parts of the overall system. For the sake ofdiscussion, assume that the sensor application 72 (FIG. 1) has beenassigned an ESID of 0x80 on the tag 11, where ESID 0x80 corresponds tothe storage section 101 having UDB type 0x80. The sensor application 72can place information in the storage section 101, such as the currentstatus of the various sensors. That information can later be retrievedfrom the storage section 101, for example by the interrogator 12 in amanner described later. In addition, information intended for the sensorapplication 72 can be placed in the storage section 101, for example bythe interrogator 12 in a manner described later. Later, that informationcan be retrieved from the storage section 101 by the sensor application72. The storage sections 101-116 with UDB types 0x80 through 0x8F arenot part of the ISO 18000-7 standard, but are potential enhancements orextensions that could be added to the 18000-7 standard.

The interrogator 12 (FIG. 1) can ask the tag 11 to send it any of thedata that is stored within the UDB data 86. For example, theinterrogator 12 can ask the tag 11 to send it the extended services list91, so the interrogator will know exactly which extended services 81 areactually installed on the particular tag 11. The interrogator 12 can askthe tag 11 to send it the alarm summary list 93, so the interrogatorwill know whether any extended service 81 on that tag currently has analarm condition that may require attention. Further, the interrogator 12can ask the tag 11 to send it one or more of the storage sections101-116, in order to provide the interrogator with more detail about oneor more of the extended services applications on the tag.

The manner in which the interrogator 12 can communicate with theextended services 81 on the tag 11 will now be described in more detail.FIG. 4 is a diagrammatic view of a digital word 128 that is contained inthe wireless signals 28 sent by the interrogator 12 to the tag 11. Thegeneral format of the digital word 128 conforms to the ISO 18000-7communication protocol. The bits of the digital word 128 areincorporated into the wireless signals 28 by serially modulating thebits onto the 433.92 MHz carrier signal using FSK modulation. The bitsof the word 128 are transmitted serially, from left to right in FIG. 4.

The digital word 128 includes several fields. The first field is apreamble 131, which is a pre-defined pattern of bits that will allow adevice receiving the signal to recognize that a wireless signal 28 isbeginning, and to synchronize itself to the wireless signal. In thedisclosed embodiment, the preamble is approximately eight bits, but thespecific number of bits can vary in dependence on factors such ascharacteristics of a particular receiver that is expected to receive thesignal.

The next field 132 in the word 128 is a protocol identification (ID)132. The protocol ID 32 identifies a communication protocol, such as aparticular version of the 18000-7 protocol, so that a device receivingthe word 128 will know what fields appear in the remainder of the word.The next field in the digital word 128 is a packet options field 133,which is a standard field that is not necessary to an understanding ofthe present invention, and is therefore not described here in detail.The next field is a packet length field 134, which is a numerical valuerepresenting the length in bytes of the entire digital word 128,excluding the preamble 131 and a postamble 141.

The next field is a tag manufacturer ID 135. The digital word 128 isused for point-to-point communications, where a particular interrogatortransmits a message to a particular tag. A given tag can be uniquelyidentified by its manufacturer and its serial number. The tagmanufacturer ID 135 is a code identifying the manufacturer of theparticular tag to which the message containing the digital word 128 isdirected.

The next field in the digital word 128 is a session ID 136. This istypically a code that uniquely identifies the interrogator 12 thattransmitted the wireless signal 28 containing the digital word 128. Thenext field contains a tag serial number 137, which is the serial numberof the specific tag to which the digital word 128 is directed.

The next field in the digital word 128 is a command operation code(opcode) 138. When the tag 11 receives a wireless signal 28 containingthe digital word 128, the operation code 138 tells the tag what itshould do in response to the signal. In the disclosed embodiment, theopcode 138 can be one of a number of different opcodes that arespecified in the ISO 18000-7 standard. Alternatively, as discussed inmore detail later, the opcode field 138 may contain a new and uniqueopcode that is not yet part of the ISO 18000-7 standard, but could beadded to the standard as an enhancement or extension.

The command opcode 138 is followed by a command parameters field 139.The command parameters field 139 may or may not be present, depending onwhich opcode appears in the command opcode field 138. That is, somecommands involve only an opcode and no parameters, and in that case thecommand parameters field 139 would not be present. However, mostcommands do require one or more parameters in addition to the opcode,and thus the command parameters field 139 will typically be present.However, the length and content of the command parameters field 139 willvary from opcode to opcode.

The next field in the digital word 128 is an error control field 140containing a value that is a cyclic redundancy code (CRC).Communications between the interrogator 12 and the tag 11 often occur inenvironments that have relatively high noise levels. Therefore, it isdesirable for a receiving device to be able to evaluate whether the word128 that it received in a wireless signal 28 is correct, or has errors.Consequently the error control field 140 is included in the digital word128 in order to permit the receiving device to identify and/or correcterrors. Although the disclosed embodiment uses a CRC value, it wouldalternatively be possible to use any other suitable error detectionand/or correction scheme, such as parity bits, or a forward errorcorrection (FEC) code.

The next field in the digital word 128 is a postamble 141, or in otherwords a packet end field. This field signals to a receiving device thatthe transmission is ending. In the disclosed embodiment, the postamble141 has eight bits that are all set to a binary zero. However, thepostamble 141 could alternatively have some other suitableconfiguration. The command opcode field 138 and the command parametersfield 139 together constitute a command 143. Some examples of differentcommands that could appear at 143 are discussed later.

As explained above, when the tag 11 receives the digital word 128, thecommand opcode 138 instructs the tag to take some type of action.Sometimes this action does not require the tag 11 to send any reply backto the interrogator 12. Typically, however, the tag 11 will need to senda reply to the interrogator 12. FIG. 5 is a diagrammatic view of adigital word 148 that is contained in wireless signals transmitted at 28from the tag 11 to the interrogator 12 in response to receipt by the tagof a wireless signal 28 containing a digital word such as that shown at128 in FIG. 4. The general format of the digital word 148 conforms tothe ISO 18000-7 communication protocol. The digital word 148 includesseveral fields. The first two fields are a preamble 151 and a protocolID 152. The preamble 151 is equivalent to the preamble 131 in digitalword 128 (FIG. 4). The protocol ID 152 will normally be identical to theprotocol ID 132 (FIG. 4) in the digital word 128 to which the receiveddigital word 148 is a reply.

The next field is a tag status field 153. This field contains certainstatus information regarding the tag that is transmitting the digitalword 148. For example, the tag status field 153 contains a bit that isset if the tag needs some type of service. This bit will be set if thebattery 63 (FIG. 1) is low and needs to be replaced. The details of thetag status field 153 are known in the art, are not necessary to anunderstanding of the unique aspects of the present invention, and aretherefore not discussed in further detail here.

The next field in the digital word 148 is a packet length 154, which isthe total number of bytes in the digital word 148, excluding thepreamble 151 and a postamble 161. The next four fields are a session ID155, a tag manufacturer ID 156, a tag serial number 157, and a commandopcode 158, which are respectively identical to the fields 136, 135, 137and 138 in the previously-received digital word 128 to which the digitalword 148 is a reply. The tag 11 may be simultaneously communicating withtwo or more interrogators, and the session ID 155 ensures that oneinterrogator accepts the digital word 148, while other interrogatorsrecognize the digital word is not for them and discard it. The tagmanufacturer ID 156 and tag serial number 157 uniquely identify the tag11 that is transmitting the digital word 148. The interrogator 12 willtypically be communicating simultaneously with a large number of tags,and the tag manufacturer ID 156 and tag serial number 157 will tell theinterrogator exactly which tag sent the digital word 148. The commandopcode 158 tells the interrogator 12 exactly which of its prior commandsthe tag is replying to by sending the digital word 148.

The next field in the digital word 148 is a response parameters field159, the size and configuration of which will vary in dependence on theopcode that appears in field 158. The last two fields in the digitalword 148 are an error control field 160 containing a CRC code, and apostamble 161. The fields 160 and 161 are functionally equivalent to thefields 140 and 141 in the digital word 128. The command opcode field 158and the response parameters field 159 together constitute a response163. Some examples of different responses that may appear at 163 arediscussed later.

FIG. 6 is a diagrammatic view of a command 143A that is one example of acommand that can appear at 143 in the digital word 128 of FIG. 4. Thecommand 143A is an extended services command that includes a commandopcode field 171 followed by a command parameters field 139A. Theextended services command 143A does not exist under the current ISO18000-7 protocol, but instead is a new and unique extension orenhancement that could be added to the 18000-7 protocol. In thedisclosed embodiment, the command opcode 171 for this command is 0x27,which is an opcode that does not exist in the current ISO 18000-7protocol. This command opcode 171 would appear in the command opcodefield 138 of the digital word 128 in FIG. 4.

The command parameters 139A include a sequence ID 172, an extendedservices ID (ESID) 173, and a payload 174. The sequence ID 172 is usedin situations where a single wireless transmission is not sufficient todeliver the entire payload to the tag. For example, the amount ofinformation that needs to be sent in the payload field 174 may be largerthan the maximum permissible size of the payload field, and the maximumpermissible size of the payload field may vary as a function of localgovernment regulations regarding wireless transmissions. Consequently,where necessary, the sequence ID 172 is used to identify a specificsegment of a multiple-segment transmission, and also to indicate thenumber of segments yet to be transmitted. In more detail, if theinformation to be sent is large and is therefore split into N segmentsthat will each be transmitted separately, the sequence ID 172 in thefirst transmission is set to N−1, the sequence ID in the nexttransmission is set to N−2, and so forth, until the sequence ID in thefinal transmission is set to zero (0). The tag 11 would collect andassemble all segments of the overall transmission before deliveringanything to the designated extended services application. If theinformation to be sent is not large and can be sent in a singletransmission without being split, then the sequence ID 172 for thatfirst and only transmission is set to zero (0).

As discussed earlier, each of the extended services 81 (FIG. 1) in thetag 11 is assigned a unique ESID, which is one of the values from 0x80to 0x8F. The ESID field 173 contains one of these ESIDs, and thusuniquely identifies a particular one of the extended services 81 on thetag 11 to which the command 143A relates. The payload 174 containsinformation that the main program 71 of the tag 11 extracts from thecommand 143A, and then places in the respective mailbox or storagesection 101-116 assigned to the particular extended services programidentified by the ESID field 173. The main program 71 then notifies thedesignated extended services application that this information ispresent in the mailbox. The main program 71 of the tag 11 merely storesthe payload 174 in the mailbox of the designated extended servicesprogram, without any study or analysis of the content of the payload.Some examples of information that can be in the payload 174 arediscussed later. Although in the disclosed embodiment the main program71 merely stores the payload 174 in the mailbox of the designatedextended services program, it would alternatively be possible for themain program 71 to bypass the mailbox, and instead deliver the payloaddirectly to the extended services application.

FIG. 7 is a diagrammatic view of a response 163A that is an example of aresponse to the specific command 143A of FIG. 6, and that can appear asthe response 163 in the digital word 148 of FIG. 5. The response 163A isan extended services reply, or in other words a reply to the extendedservices command shown in FIG. 6. The extended services reply 163A ofFIG. 7 may or may not be sent to the interrogator, depending for exampleon which extended services application is identified by the extendedservices ID 173 in the command 143A of FIG. 6. The extended servicesreply 163A does not exist under the current ISO 18000-7 protocol, butinstead is an extension or enhancement that could be added to the18000-7 protocol.

The response 163A includes a command opcode field 181, a sequence IDfield 182, and an ESID field 183, the contents of which are respectivelyidentical to the command opcode 171, sequence ID 172 and ESID 173 in thecommand 143A to which the tag is responding. The payload 184 may besimply an acknowledgement by the tag 11 that the payload 174 of thereceived command 143A has been delivered to the mailbox of the extendedservices application identified by the ESID 173 in that receivedcommand. Alternatively, the payload 184 may be a reply from theparticular extended services application identified by ESID 173 in thecommand 143A. Where the payload 184 is a reply from an extended servicesapplication, the tag 11 does not study or analyze the content of thepayload 184. The tag 11 simply takes the payload 184 from the designatedone of the extended services 81, or from the mailbox for thatapplication, and forwards the payload 184 to the interrogator 12 withoutchange. Where the payload 184 is a reply from an extended servicesapplication, the length of the payload 184 can vary, and is undercontrol of the particular extended services application that generatesthe payload. Some examples of information that can be in the payload 184are discussed later. In some cases, after an extended servicesapplication receives the command 143A, it may not be able to providerequested information for the payload 184 within a time limit imposed bythe ISO 18000-7 standard. In that case, the extended servicesapplication can instead promptly provide for the payload 184 an interimreply indicating that its actual reply will be delayed. Then, theinterrogator 12 can later issue another command 143A to actuallyretrieve the actual reply. In other situations, the information providedby the extended services application may be larger than the maximumpermissible size of the payload 184. In that event, the information canbe put into the mailbox assigned to that particular extended servicesapplication, and then the payload 184 can be used to notify theinterrogator that the information is in the mailbox and is waiting to beretrieved in a manner discussed below.

FIG. 8 is a diagrammatic view of a different command 143B that mayappear at 143 in the digital word 128. The command 143B is a read UDBcommand that is defined in the current ISO 18000-7 standard. The command143B includes a command opcode 191 of 0x70, and command parameters 139B.The command parameters 139B include a UDB type code field 192. The valuein field 192 identifies one of the various UDB types in the UDB data 86(FIG. 3). For example, with reference to the left side of FIG. 3, theUDB type code at 192 in FIG. 8 may be 0x00, or one of 0x80 through 0x8F.The next field 193 in the command parameters 139B is an offset valuerepresenting an offset into the data corresponding to the UDB type codeappearing at 192. Thus, for example, where the interrogator 12 wishes toread a large amount data from the UDB data 86, the interrogator can sendmultiple separate commands that request respective segments of the data,and each such command would have a respective different offset value at193 in order to uniquely identify the start of each such data segment.

The last of the command parameters 139B is a maximum packet length value194. When a tag eventually replies to the command 143B, the field 194specifies the maximum permissible length of a packet returned by thetag. In other words, the field 194 specifies the maximum value that canappear in the packet length field 154 of the digital word 148 (FIG. 5).The tag can elect to use a packet length less than the maximum lengthspecified in field 194, but the tag is not permitted to use a largerpacket length. Over time, the interrogator may elect to adjust themaximum packet length value that it puts in the field 194 of transmittedmessages, based on factors such as ambient operating conditions. Forexample, if the interrogator 12 and tag 11 are currently operating in anoisy environment, the interrogator may elect to reduce the maximumpacket length value presented in the field 194 of transmitted messages.Later, if the environment becomes less noisy, the interrogator may electto increase the maximum packet length value presented in the field 194of transmitted messages.

FIG. 9 is a diagrammatic view of a response 163B that is transmitted bythe tag 11 in response to the command 143B of FIG. 8, and that canappear as the response 163 in the digital word 148 of FIG. 5. Theresponse 163B has a format that is defined in the current ISO 18000-7standard. The response 163B includes a command opcode 201 followed by aresponse parameters field 159B, where the response parameters fieldincludes a UDB type code field 202, a UDB type total length field 203, arequested offset field 204, and a UDB data field 205.

The fields 201, 202, and 204 are identical to the fields 191, 192 and193 in the particular command 143B to which the tag is responding. Thefield 203 identifies the total amount of data (in bytes) that theparticular tag currently has stored in the UDB data 86 (FIG. 3) for thespecified UDB type. Thus, for example, if the UDB type is specified tobe 0x80, the field 203 will identify the total number of bytes of datathat are currently stored in the storage section 101 of the UDB data 86.This tells the interrogator 12 how much data of the specified UDB typeis currently stored in the tag, so the interrogator 12 knows how muchdata is available to be retrieved. The UDB data field 205 contains anactual segment of data from the UDB data 86, presented in TLD format.

FIG. 10 is a diagrammatic view of one specific example of UDB data 205Athat can appear in the field 205 of the response 163B in FIG. 9. The UDBdata 205A includes a UDB element type field 211. This field is used todistinguish different element types within a given UDB type. Forexample, with reference to FIG. 3, UDB type 0x00 encompasses severaldifferent types of data, including the extended services list 91 and thealarm summary list 93. The extended services list 91 is identified asUDB element type 0x17, whereas the alarm summary list 93 is identifiedas UDB element type 0x18. These two UDB element types do not exist underthe current ISO 18000-7 protocol, but instead represent an extension orenhancement that could be added to the 18000-7 protocol. In FIG. 10, theUDB element type field 211 contains the value 0x17 to indicate that theUDB data 205A contains the extended services list 91 from FIG. 3.

The next field in the UDB data 205A is a length field 212, whichcontains a numerical value identifying the length in bytes of the datathat follows the length field 212. In FIG. 10, the data includes severalitems 213 through 215 that each identify a respective one of theextended services 81 (FIG. 1) actually installed on the tag 11. Onlyextended services that are actually installed on the tag are listed. Ifno extended services are currently installed on the tag, then none ofthe items 213-215 will be present, and the length field 212 will containa zero. The items 213-215 all have the same format, and the item 213 isexpanded to show this format.

More specifically, the item 213 includes a description type field 231, alength field 232, an ESID field 233, and a data field 234. In thedisclosed embodiment, the description type field 231 contains either avalue 0x00 or a value 0x01, to specify the format for the data field234. In particular, if the description type field 231 contains the value0x00, then the data field 234 uniquely identifies the particularextended services application by setting forth a previously-assignednumerical value unique to that application. Alternatively, if thedescription type field 231 contains the value 0x01, then the data field234 contains a string of ASCII characters uniquely identifying theparticular type of extended services application.

The length field 232 gives the length in bytes of the fields 233 and234, and the ESID field 233 contains the ESID value assigned by the tagto the particular extended services application to which item 213corresponds. The interrogator 12 can use the ESID value in field 233 touniquely identify the particular extended services application insubsequent communications, and will know from the data field 234 exactlywhat type of extended services application it is working with.

FIG. 11 is a diagrammatic view of a different example of UDB data 205Bthat could appear at 205 in the response 163B of FIG. 9. The UDB data205B includes a UDB element type field 241, a length field 242, and someESID fields 243-245. The UDB element type field 241 contains a value0x18, to indicate that the data in the UDB data 205B is the alarmsummary list 93 (FIG. 3) from the UDB data 86. The length field 242contains a numerical value representing the length in bytes of all theESID fields 243-245. The fields 243-245 do not necessarily identify allextended services applications 81 that are currently installed on thetag 11. Instead, the fields 243-245 identify only those extendedservices applications 81 that currently have an active alarm of sometype. If no extended services application currently has an active alarm,then none of the fields 243-245 will be present, and the length field242 will contain a value of zero.

FIG. 12 is a diagrammatic view of still another example of UDB data 205Cthat could appear at 205 in the response 163B of FIG. 9. As discussedabove, the command 143B of FIG. 8 can specify a particular UDB type codein field 192, and this can be one of the type codes 0x80 through 0x8Fthat correspond to the storage sections or mailboxes 101-116 in the UDBdata 86 (FIG. 3). In FIG. 12, the UDB data 205C includes several TLDblocks 248-249, each of which includes a type field, a length field anda data field. The data fields of these TLD blocks contain some or all ofthe data from the specified storage section or mailbox 101-116. AlthoughFIG. 12 shows a series of TLD blocks, the UDB data 205C could includeonly a single TLD block, if the corresponding storage section containedonly a single data element. Further, if the corresponding storagesection did not happen to contain any data, the UDB data 205C would noTLD blocks, and would have a length of zero.

As explained earlier, the interrogator 12 and any of the extendedservices 81 can directly exchange information with each other, whereinformation from the interrogator 12 is placed in the payload 174 of theextended services command 143A shown in FIG. 6, and information from theparticular extended service is either placed in the payload 184 of theextended services response 163A shown in FIG. 7, or placed in the UDBdata field 205 of the read UDB reply 163B shown in FIG. 9. Thistechnique can be referred to as “tunneling” information through the ISO18000-7 wireless signals 28 and the main program 71 of the tag 11. Forsimplicity and clarity, a discussion will first be provided of certainexchanges that can occur between the interrogator 12 and the sensorapplication 72 (FIG. 1) that manages the three sensors 51-53. As oneaspect of this, the interrogator 12 and the sensor application 72 canexchange information in a manner conforming to an industry-standardprotocol commonly known as ISO 21451.7, which is based on anotherindustry-standard protocol commonly know as IEEE 1451.7. As used herein,the term ISO 21451.7 refers to a specific version of that standard,which is ISO/IEC/IEEE WD 21451.7, 2009-07-13. And as used herein, theterm IEEE 1451.7 refers to a specific version of that standard, which isIEEE P1451.7/D1.0, October 2008. The interrogator 12 and sensorapplication 72 can also carry out information exchanges in a manner thatis not currently part of either the ISO 21451.7 standard or the IEEE1451.7 standard, but that involves new and unique enhancements orextensions that could be added to these standards.

FIG. 13 is a diagrammatic view of one example of a payload 174A thatcould appear as the payload 174 in the extended services command 143A ofFIG. 6. The payload 174A is a new read-sensor-identifier command thatdoes not exist under the current ISO 21451.7 protocol, but instead is anextension or enhancement that could be added to the 21451.7 protocol. Inthis regard, ISO 21451.7 and IEEE 1451.7 ach include aread-sensor-identifier command, but it can only read informationregarding a single sensor. In contrast, the new read-sensor-identifiercommand in payload 174A will cause the sensor application 72 to return asingle reply that identifies all sensors associated with the tag 11.

The command in payload 174A includes a 5-bit command field 321, a 1-bitparameter field 322, and a 2-bit field 323 containing padding bits. Thecommand field 321 contains a unique code identifying theread-sensor-identifier command. The parameter field 322 contains asingle bit that identifies a format the sensor application 72 should usein its reply to identify each sensor. In particular, if the bit in theparameter field 322 is a binary “0”, then the sensor application 72 willidentify each sensor with the serial number of the sensor, and a uniquesensor ID code that is sometimes referred to as a port address. On theother hand, if the bit in the parameter field 322 is a binary “1”, thenthe sensor application 72 will identify each sensor by providing theunique sensor ID code for the sensor, and fields 1-3 from a transducerelectronic data sheet (TEDS) for that particular sensor.

In this regard, and as is known in the art, a TEDS for a given sensor isessentially a table having a series of pre-defined fields that eachprovide information about a respective characteristic of the sensor.Under the TEDS standard, field 1 is a 3-bit field that normally containsthe binary value “001”. Field 2 is a 7-bit field containing a value thatidentifies the particular type of sensor, such as whether the sensor isa temperature sensor, a shock sensor, a humidity sensor, and so forth.Field 3 is a 5-bit field used only for certain types of sensors, inparticular to identify a specific sub-type of the general sensor typeidentified in field 2. For example, if field 2 indicates that the sensoris a chemical sensor, field 3 will identify the particular type ofchemical sensor.

Turning to the padding bit field 323, the ISO 21451.7 and IEEE 1451.7protocols are bit-based protocols, whereas the ISO 18000-7 protocol is abyte-based protocol. In FIG. 13, the 5-bit command field 321 and the1-bit parameter field 322 total up to six bits, which is less than abyte. The 2-bit field 323 of padding bits is therefore provided toensure that the payload 174A has an overall size of one byte. The field323 contains a binary value of “00”. The bits in the field 323 have nosubstantive meaning, and are discarded by the sensor application 72after it receives the payload 174A sent by the interrogator.

FIG. 14 is a diagrammatic view of a payload 184A that can appear as thepayload 184 of the extended services response 163A shown in FIG. 7.After the sensor application 72 receives the command 321 in the payload174A, it prepares the payload 184A of FIG. 14 and returns it to theinterrogator 12 as a read-sensor-identifier reply. Theread-sensor-identifier reply in the payload 184A of FIG. 14 does notexist under either the current ISO 21451.7 protocol or the current IEEE1451.7 protocol, but instead is an extension or enhancement that couldbe added to these protocols.

In more detail, the payload 184A includes several fields 331 through337. Field 331 is a 5-bit response field containing identically the samecode that appeared in the command field 321 of the payload 174A. Thenext field is a 1-bit NAK field. This field contains a binary “0” toindicate that the sensor application 72 did not encounter any error inexecuting the command specified at 321 in the payload 174A. If an errorhad occurred, then the NAK field would contain a binary “1”, but in thatcase the remainder of the payload would have a different format, asdiscussed in more detail later.

The next field 333 of the payload 184A is a 4-bit numerical valuespecifying the total number of sensors associated with the tag 11. Thefield 333 is followed by several fields 334 through 336 that eachprovide identifying information for a respective one of the sensors inthe tag. The number of fields 334-336 will be equal to the numericalvalue appearing in field 333. If the tag has no sensors, then field 333will contain a value of zero, and none of the fields 334-336 will bepresent. When present, the fields 334-336 each have a length of either22 bits or 71 bits, as discussed in more detail below. The last field337 in the payload 184A is only present if needed, and contains paddingbits to the extent needed to ensure that the overall length of thepayload 184A is an integer number of bytes.

As discussed above, the fields 334 through 336 that identify respectivesensors can each have one of two different formats, and these twoalternative formats are each shown in the lower portion of FIG. 14. Inparticular, if the parameter bit 322 in the payload 174A of FIG. 13 is abinary “0”, then each of the fields 334 through 336 will contain twofields 341 and 342. Field 341 is a 7-bit field containing the uniquesensor ID or port address discussed above, and field 342 is a 64-bitfield containing a numerical value that is the serial number of theparticular sensor. Fields 341 and 342 together contain a total of 71bits. On the other hand, if the parameter bit 322 in the payload 174A ofFIG. 13 is a binary “1”, then the fields 334-336 will each contain fourfields 346 through 349. Field 346 is a 7-bit field containing the samesensor ID that would appear in field 341, and fields 347 through 349 arerespectively a 3-bit field, a 7-bit field, and a 5-bit field thatrespectively contain TEDS fields 1 through 3. Fields 346 through 349together contain a total of 22 bits.

FIG. 15 is a diagrammatic view of a payload 174B that is an alternativeexample of a payload that could appear as the payload 174 of theextended services command 143A in FIG. 6. Payload 174B contains asensor-read-records command that does not exist under either the currentISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead isan extension or enhancement that could be added to these protocols. Thepayload 174B includes five fields 361 through 365. The first field 361is a 5-bit command field containing a unique code that identifies thesensor-read-records command. The next field 362 is a 7-bit fieldcontaining the unique sensor ID or port address of a particular sensorfor which information is being requested. The interrogator will havepreviously obtained this unique sensor ID for each of the sensors, byusing the read-sensor-identifier command of FIG. 13, in response towhich it receives the IDs back in the fields 341 or 346 of the responseshown in FIG. 14.

The next field in the payload 174B is a 4-bit measurement type field 363that identifies the particular type of measurement information beingrequested. The permissible measurement type codes are identified in ISO21451.7, and are therefore not all described in detail here. But by wayof example, the interrogator could use the measurement type field 363 torequest (1) an average of the readings from the specified sensor, (2)the most recent reading from the specified sensor, (3) part or all of alog of a series of readings from the specified sensor, either with orwithout date and time information for each reading, or (4) other typesof measurement information. This information is all maintained by thesensor application 72 of FIG. 1 in the sensor data 77.

The next field 364 is 16-bit field containing a numerical valuespecifying the number of the first record to be returned from the datamaintained for the measurement type specified at 363. The next field 365is an 8-bit field containing a numerical value specifying the number ofrecords being requested. The interrogator might, for example, send afirst sensor-read-records command in which the field 364 specifiesrecord 1 and the field 365 requests 10 records. The sensor application72 would then send back ten records. The interrogator 12 might then senda second sensor-read-records command in which the field 364 specifiesrecord 11, and the field 365 specifies 10 records. The sensorapplication 72 would then return records 11 through 20.

FIG. 16 is a diagrammatic view of a payload 184B that could appear asthe payload 184 in the extended services response 163A of FIG. 7. Thepayload 184B contains a sensor-read-records reply, which the sensorapplication 72 returns in response to receipt of a sensor-read-recordscommand 174B (FIG. 15). The sensor-read-records reply in the payload184B of FIG. 16 does not exist under either the current ISO 21451.7protocol or the current IEEE 1451.7 protocol, but instead is anextension or enhancement that could be added to these protocols.

The payload 184B includes six fields 371-376. The fields 371, 373 and374 will respectively be identical to the fields 361, 364 and 365 in asensor-read-records command received from the interrogator in thepayload 174B (FIG. 15). The field 372 is a 1-bit NAK field that willcontain a binary “0” to indicate no error occurred. The field 375 willcontain the requested data. The field 376 is a padding bits field, andwill only be present where needed to ensure that the overall length ofthe payload 184B is an integer number of bytes.

FIG. 17 is a diagrammatic view of a payload 174C that is an example ofstill another payload that could appear at 174 in the extended servicescommand 143A of FIG. 6. The payload 174C contains aread-all-sensor-status command, which is a request for the sensorapplication 72 to return status information regarding each sensorassociated with the tag 11. The read-all-sensor-status command of FIG.17 does not exist under the current ISO 21451.7 protocol, but instead isan extension or enhancement that could be added to the 21451.7 protocol.This command has two fields 401 and 402. The field 401 is a 5-bit fieldcontaining a unique code that identifies this particular command. Thefield 402 is a 3-bit field of padding bits that contains a binary valueof “000”, in order to give the payload 174C an overall length of onebyte.

FIG. 18 is a diagrammatic view of a payload 184C that is a furtherexample of a payload that could appear at 184 in the extended servicesresponse 163A of FIG. 7. The payload 184C is a read-all-sensor-statusreply issued by the sensor application 72 after it receives theread-all-sensor-status command shown in FIG. 17. Theread-all-sensor-status reply of FIG. 18 does not exist under either thecurrent ISO 21451.7 protocol or the current IEEE 1451.7 protocol, butinstead is an extension or enhancement that could be added to theseprotocols.

The payload 184C includes several fields 411 through 417. The field 411is a 5-bit response field containing identically the same numerical codeas the field 401 in the command of FIG. 17. The next field 412 is a1-bit NAK field containing a binary “0” to indicate that the sensorapplication 72 did not encounter any error in executing the command ofFIG. 17. The next field 413 is a 4-bit field containing a numericalvalue identifying the total number of sensors associated with the tag11. The field 413 is followed by some fields 414 through 416 that areeach a 32-bit field containing status information for a respective oneof the sensors associated with the tag. The number of fields 414 through416 is equal to the numerical value appearing in the field 413. If thetag has no sensors, then the field 413 will contain a value of zero, andnone of the fields 414 through 416 will be present. The last field 417contains six padding bits that are each a binary “0”, to ensure that theoverall length of the payload 184C is an integer number of bytes.

Each of the fields 414 through 416 contains seven fields that are shownat 421 through 427. The field 421 is a 7-bit field containing the uniquesensor ID or port address that was discussed earlier. The next field 422is a 1-bit enabled status field that indicates whether the specifiedsensor is currently enabled or disabled. In this regard, theinterrogator 12 can send the sensor application 72 a command thatidentifies a particular sensor and indicates the sensor is to be enabledor disabled. The enabled status bit 422 indicates whether the sensor iscurrently enabled or disabled.

The next field 423 is a 4-bit field reserved for future use. This isfollowed by a 12-bit sensor type field 424, which contains fields 1through 3 of the TEDS for the specified sensor. The next field 425 is a2-bit field reserved for future use. The next field 426 is a 2-bitalarms set field. One bit indicates whether or not monitoring iscurrently enabled for a lower threshold associated with the specifiedsensor, and the other bit indicates whether or not monitoring iscurrently enabled for an upper threshold associated with that sensor.

The next field 427 is 4-bit alarms triggered field. One bit indicateswhether or not an alarm has been triggered for the upper threshold. Thenext bit indicates whether an alarm has been triggered for the lowerthreshold. The next bit indicates whether, for any of the data logsmaintained for that sensor, a memory full condition has been reached,and memory rollover has not been asserted (or is not possible toassert). The remaining bit indicates whether the specified sensor hasflagged a low battery condition, based on criteria specified by thesensor manufacturer. Where a tag has multiple sensors supported by asingle battery, such as the battery 63 of FIG. 1, a low batterycondition can cause multiple sensors to report a low battery statuscondition.

FIG. 19 is a diagrammatic view of a payload 184D that is yet anotherexample of a payload that can appear at 184 in the extended servicesresponse 163A of FIG. 7. The payload 184D contains an error reply thatdoes not exist under either the current ISO 21451.7 protocol or thecurrent IEEE 1451.7 protocol, but instead is an extension or enhancementthat could be added to these protocols. More specifically, and asdiscussed earlier, the sensor application 72 may encounter some type oferror in attempting to execute and respond to a command received fromthe interrogator 12. For example, the interrogator may ask the sensorapplication 72 to return a specified number of data records of a datatype for which the sensor application 72 currently has a smaller numberof records. The sensor application 72 therefore needs to notify theinterrogator 12 that an error has occurred. The payload 184D of FIG. 19represents an error reply that the sensor application 72 can send to theinterrogator 12 to identify an error.

The payload 184D includes five fields 451 through 455. The field 451 isa 5-bit response field that contains identically the same value as thefirst field of the particular command that triggered the error. In otherwords, the field 451 would contain the value from one of the field 321(FIG. 13), the field 361 (FIG. 15), the field 401 (FIG. 17), or thecommand field in some other command that is not discussed here. The nextfield 452 is a 1-bit NAK field that contains a binary “1” to indicate anerror has occurred. Assume for the sake of discussion that the sensorapplication 72 received the sensor-read-records command of FIG. 15. Theinterrogator 12 would receive back a response beginning with a 5-bitfield containing the code from field 361 of the command, followed by the1-bit NAK field. The interrogator would look at the first five bits ofthe response to identify the corresponding command, and would then lookat the 1-bit NAK field to determine whether or not an error occurred. Ifthe NAK bit is a binary “0”, then the interrogator knows that no erroroccurred, and that the NAK field will be followed by the four fields371-376 shown in FIG. 16. In contrast, if the 1-bit NAK field is abinary “1”, then the interrogator knows that an error occurred, and thatthe remainder of the message will be the three fields 453-455 shown inFIG. 19.

In FIG. 19, the NAK field 452 is followed by a 6-bit error code field453. This field contains a code or a numerical value that uniquelyidentifies the particular error encountered by the sensor application72. The error code field 453 is followed by an optional data field 454.The data field 454 may or may not be present, depending on the errorcode in field 453. That is, some error codes may be accompanied byrelated data that appears in the field 454, while other error codes mayhave no need to return related data. As to errors that do return data inthe field 454, the size of the data field may vary from one type oferror to another. The last field 455 is a padding bits field that may ormay not be present. It will be included where necessary to ensure thatthe overall length of the payload 184D is an integer number of bytes.

The foregoing discussion has given several specific examples of how theinterrogator 12 and sensor application 72 can communicate with eachother using the payload 174 (FIG. 6) and the payload 184 (FIG. 7). Thepayloads 174 and 184 can also be used to effect communication betweenthe interrogator 12 and any of the other extended services applications81 (FIG. 1) that are present in the tag 11. The commands and repliesdiscussed in association with FIGS. 13 through 19 are specific to thesensor application 72, and include some extensions or enhancements tothe ISO 21451.7 and IEEE 1451.7 standards, which relate specifically tosensors.

As to communications between the interrogator 12 and other extendedservices applications 81, the manufacturer or author of each extendedservices application 81, such as those shown at 73 to 75 in FIG. 1,would define formats for commands and replies that are customized tosuit the particular function and operation of that extended servicesapplication. It is not necessary to describe here in detail a separatecommand and reply structure for each of the extended servicesapplications 73-75 in FIG. 1. As discussed earlier, the extendedservices applications 81 in FIG. 1 are merely exemplary, and there are avariety of other extended services applications that could beimplemented on the tag 11.

Although a selected embodiment has been illustrated and described indetail, it should be understood that a variety of substitutions andalterations are possible without departing from the spirit and scope ofthe present invention, as defined by the claims that follow.

What is claimed is:
 1. An apparatus comprising a radio frequencyidentification tag having a main section that provides basic radiofrequency identification functionality, that has an extended servicesinterface, and that receives wireless signals containing a message typewhich includes an extended services segment and which is an extension toan industry-standard communication protocol, said main sectionresponding to receipt of a wireless signal containing a messageconforming to said message type by transmitting said extended servicessegment thereof through said extended services interface.
 2. Anapparatus according to claim 1, wherein said communication protocol isthe ISO 18000-7 communication protocol.
 3. An apparatus according toclaim 1, wherein said extended services segment is an extension to anindustry-standard further communication protocol that is different fromsaid communication protocol for said wireless signals.
 4. An apparatusaccording to claim 3, wherein said tag includes a further section thatincludes a sensor and that that receives said extended services segmentfrom said main section through said extended services interface, saidfurther communication protocol being one of the IEEE 1451.7communication protocol and the ISO 21451.7 communication protocol.
 5. Anapparatus according to claim 1, including a further section thatprovides extended services functionality different from said basicfunctionality, and that receives said extended services segment fromsaid main section through said extended services interface.
 6. Anapparatus according to claim 5, wherein said further section is part ofsaid tag.
 7. An apparatus according to claim 5, wherein said furthersection is physically separate from said tag.
 8. An apparatus accordingto claim 5, wherein said extended services functionality includesprovision of security for said tag.
 9. An apparatus according to claim5, wherein said further section includes one of a sensor, a receivercircuit that receives wireless satellite signals containing positioninginformation, and a real time locating circuit.
 10. An apparatusaccording to claim 5, wherein said further section includes a pluralityof sensors, and a single instantiation of an application that interfaceseach of said sensors to said extended services interface, and that iscompatible with and also implements an extension to one of IEEE 1451.7and ISO 21451.7.
 11. An apparatus according to claim 1, wherein saidmain section responds to receipt through said extended servicesinterface of a further segment by transmitting a further wireless signalthat conforms to said communications protocol and that contains saidfurther segment.
 12. An apparatus comprising a radio frequencyidentification tag having a main section that provides basic radiofrequency identification functionality, that has an extended servicesinterface, and that receives wireless signals, said main section storingdata that includes respective information regarding each extendedservice accessible through said extended services interface, and saidmain section responding to receipt of a wireless signal containing aselected command that is an extension to a command set of anindustry-standard communication protocol by transmitting a furtherwireless signal containing a message that is an extension to saidcommunication protocol and that contains at least part of said data. 13.An apparatus according to claim 12, wherein said communication protocolis the ISO 18000-7 communication protocol.
 14. An apparatus according toclaim 12, wherein said data includes a list identifying each extendedservice that is accessible through said extended services interface,said further wireless message including at least part of said list. 15.An apparatus according to claim 12, wherein said data includes a listidentifying each extended service that is accessible through saidextended services interface and that currently has an active alarmcondition, said further wireless message including at least part of saidlist.
 16. An apparatus according to claim 12, wherein said dataincludes, for each extended service that is accessible through saidextended services interface, a respective segment containing informationreceived through said extended services interface and relating to thecorresponding extended service, said further wireless message includingat least part of a respective said segment.
 17. An apparatus accordingto claim 12, including a further section that provides extended servicesfunctionality different from said basic functionality, and that iscoupled to said extended services interface.
 18. An apparatus accordingto claim 17, wherein said further section is part of said tag.
 19. Anapparatus according to claim 17, wherein said further section includes aportion that is physically separate from said tag.
 20. An apparatusaccording to claim 17, wherein said extended services functionalityincludes provision of security for said tag.
 21. An apparatus accordingto claim 17, wherein said further section includes one of a sensor, areceiver circuit that receives wireless satellite signals containingpositioning information, and a real time locating circuit.
 22. Anapparatus according to claim 17, wherein said further section includes aplurality of sensors, and a single instantiation of an application thatinterfaces each of said sensors to said extended services interface,that is compatible with one of IEEE 1451.7 and ISO 21451.7, and thatimplements an extension to said one of IEEE 1451.7 and ISO 21451.7. 23.An apparatus comprising a radio frequency identification tag having asection that sends and receives wireless signals and that has amulti-sensor interface, said section responding to receipt of a wirelesssignal containing a request by transmitting a further wireless signalcontaining information regarding multiple sensors.
 24. An apparatusaccording to claim 23, wherein said request and said information conformto an extension of an industry-standard sensor communication protocol.25. An apparatus according to claim 24, wherein said sensorcommunication protocol is one of IEEE 1451.7 and ISO 21451.7.
 26. Anapparatus according to claim 25, wherein said section includes a singleinstantiation of a multi-sensor application that is coupled to saidmulti-sensor interface, that is compatible with one of IEEE 1451.7 andISO 21451.7, and that implements an extension to said one of IEEE 1451.7and ISO 21451.7.
 27. An apparatus according to claim 23, wherein saidinformation in said further wireless signal includes an identificationof each sensor.
 28. An apparatus according to claim 23, wherein saidinformation in said further wireless signal includes status informationregarding each sensor.
 29. An apparatus according to claim 23, whereinsaid tag includes a plurality of sensors, said section interacting witheach said sensor through said interface.
 30. An apparatus according toclaim 23, wherein said wireless signals conform to a communicationprotocol.